Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a data stream. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of a session, and negotiation of cryptographic keys to be used during the session. IPsec can be used to protect data flows between a pair of hosts (e.g. computer users or servers), between a pair of security gateways (e.g. routers or firewalls), or between a security gateway and a host.
IPsec uses the concept of a Security Association (SA) as the basis for building security functions into IP. A Security Association can be seen as a set of security information relating to a given network connection or set of connections, as described in RFC 2401 “Security Architecture for the Internet Protocol” (November 1998).) In general, a Security Association is simply the bundle of algorithms and parameters (such as keys) that is used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bi-directional traffic, the flows are secured by a pair of Security Associations. The actual choice of encryption and authentication algorithms (from a defined list) is left to the IPsec administrator. Security Associations are stored in a Security Association Database (SADB). The SADB is part of the a key engine unit that is typically implemented in the kernel of an operating system.
In order to decide what protection is to be provided for an outgoing packet, IPsec uses the Security Parameter Index (SPI), an index to the SADB, along with the destination address in a packet header, which together uniquely identify a Security Association for that packet. A similar procedure is performed for an incoming packet, where IPsec gathers decryption and verification keys from the SADB.
The PF_KEY API version 2, described in RFC 2367 “PF_KEY Management API, Version 2” (July 1998), is a generic Application Interface (API) that provides an interface between the key kengine unit and trusted key management applications. PF_KEY is a message based socket protocol that can be extended with new proprietary messages. The existing messages can be extended with new parameters that are realized by extension headers.
The PF_KEY API provides key management applications with an interface for numerous operations like adding, listing or deleting SA associations. Furthermore, the key kengine unit can notify the key management applications about certain events. This is described in more detail in RFC 2367, but important operations include the following:
SADB_ADD is used by key management applications to insert SAs into the SADB.
SADB_GETSPI is used to insert a placeholder for an SA in the SADB, when the details are not yet known.
SADB_UPDATE is used to update existing SAs or placeholders previously inserted using SADB_ADD or SADB_GETSPI.
SADB_FLUSH is used to delete all the entries in the SADB.
SADB_DUMP can be used for dumping all entries in the SADB. It is mainly used for testing or debugging reasons and key management applications do not depend on this message for basic operation.
RFC 2367 stipulates that only trusted privileged key management applications are permitted to open PF_KEY sockets. However, the PF_KEY socket protocol does not differentiate between different key management applications. If the PF_KEY API is in use by more than one key management application, it can easily happen that an operation by one key management application has unwanted impacts on the Security Associations inserted by other key management applications.
For example, one key management application can empty the whole SADB using the SADB_FLUSH PF_KEY message. This can have undesired effects on other key management applications, since their Security Associations will be deleted. The PF_KEY socket protocol does not include a message that removes only those Security Associations that were inserted by a given key management application.